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(54) Method and system for secure pervasive access 



(57) The present invention relates to a client-server 
system having a security system for controlling access 
to application functions. The security system separated 
from the clients and the application functions routes ail 
incoming requests created by various PVC-devices to 
a centralized security system providing an authentica- 
tion component and a security component. The authen- 
tication component provides several authentication 
mechanism which may be selected by information con- 



tained in the client's request. The authentication mech- 
anism may be changed or extended without changing 
conditions on the client as well on the server or applica- 
tion side. The security component provides a security 
policy describing security requirements for accessing 
application functions which may be invoked by the se- 
curity component. If the selected authentication mech- 
anism succeeds and fulfills the security policy associat- 
ed to that application function then the application func- 
tion will be invoked by the security component (FIG. 3). 
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Description 

Technical Field 

[0001] The present invention relates to method and 
system for controlling access from different Pervasing 
Computing Devices (PVC-devices) to applications in- 
stalled on or accessible via a server. 

Background of the invention 

[0002] PVC-devices, e.g. personal digital assistants, 
mobile phones, chipcards etc., are frequently used to 
gather information or to use business transactions ap- 
plications stored on server, e.g. application for electron- 
ic payments or application for electronic shopping. 
[0003] Wireless PVC-devices like personal digital as- 
sistants and mobile phones communicate via gateway 
and Internet to a server which offers access to Web pag- 
es or business transaction application. Other PVC-de- 
vices like chipcards may use a LAN, Intranet or Internet 
to communicate with the said server. 
[0004] A main problem of communication between 
different PVC-devices and the business transaction ap- 
plications is the security. Normally each business trans- 
action application may use its own security require- 
ments depending on the type of PVC-device, the type 
of user and type of communication. 
[0005] Security requirements may consist of an au- 
thentication level, a confidentiality level and an endorse- 
ment level. PVC-devices can establish a certain authen- 
tication level by performing appropriate authentication 
protocol and a certain level of confidentiality by employ- 
ing appropriate encryption to secure communication be- 
tween the server and certain level of endorsement. 
[0006] Today, to applicant's knowledge, no secure, in- 
tegrated solution for security based access control from 
various PVC-devices to applications/functions on a 
server exists. Applications are mostly developed to sup- 
port few devices. Security requirements and authenti- 
cation code are mostly buried in the application code. 
[0007] In current PVC-applications, it is difficult to add 
support for additional PVC-devices and authentication 
mechanism. In most cases, applications allow for at 
most one authentication mechanism, mostly coupled 
with an application. 

[0008] It is therefore the object of the present inven- 
tion to provide a system and method for a security based 
access control from various PVC-devices to applica- 
tions which is independent from any client or application. 
[0009] This object is solved by the features of the in- 
dependent claims. Preferred embodiments of the 
present invention are laid down in the dependent claims. 

Summary of the invention 

[001 0] The present invention relates to a client-server 
system having a security system for controlling access 



to application functions. The security system separated 
from the clients and the application functions routes all 
incoming requests created by various PVC-devices to 
a centralized security system providing an authentica- 
5 tion component and a security component. The auth en- 
tication component provides several authentication 
mechanism which may be selected by information con- 
tained in the client's request. The authentication mech- 
anism may be changed or extended without changing 
10 conditions on the client as well on the server or applica- 
tion side. The security component provides a security 
policy describing security requirements for accessing 
application functions which may be invoked by the se- 
curity component. If the selected authentication mech- 
15 an ism succeeds and fulfills the security policy associat- 
ed to that application function then the application fu no- 
tion will be invoked by the security component. 
[0011] In a preferred embodiment, the present inven- 
tion provides a session object for each PVC-device that 
20 communicates with the server. One of the session ob- 
ject's attributes is a security state. The security state at 
least indicates the level of security of authentication 
and/or the level of confidentiality of communication with 
the PVC-device. The server has a security policy, that 
25 determines which application function may be invoked 
at what security level. Application functions on a server 
can only be invoked via the Secure Pervasive Access 
Framework (SPAF). For each request to invoke a appli- 
cation function, SPAF checks whether the security state 
30 of the client device satisfies the access conditions de- 
fined in the security policy for that application function; 
only if this is the case, SPAF invokes the requested ap- 
plication function. 

[0012] Preferably all incoming requests are routed 
through the Device Adaptation Layer. This layer in- 
cludes different kinds of gateways that convert device 
specific requests to a canonical form, i.e. HTTP re- 
quests that carry information about the device type and 
the desired reply content type, e.g. HTML, WML or 
VXML. Examples of such gateways are voice gateways 
with a VXML browser that recognizes speech and gen- 
erates HTTP requests that carry text and selected op- 
tions or a WAP gateway that connects the WAP protocol 
stack to the Internet protocol stack. 
[0013] SPAF checks all incoming requests and in- 
vokes application function according to the associated 
security policies, which may be stored in a special da- 
tabase, for example. The security policies may be very 
different, for example one non-sensitive application 
function may only have functions that accessible to eve- 
rybody, while another application may have certain func- 
tions that may only be performed by clients that have 
been authenticated by the security module using a cryp- 
tographic protocol. 

[0014] Calls of application functions by SPAF result in 
execution of application logic, maybe including access 
to databases or legacy systems in the background and 
some output that must be delivered to the user. All in- 
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formation to be displayed is prepared by the application 
logic and passed to the content delivery module. The 
content delivery module renders this information into 
content that depends on the device type and desired re- 
ply content type. 5 

Brief Description of the Drawings 

[001 5] The present invention will be better understood 
and its numerous objects and advantages will become 10 
more apparent to those skilled in the art by reference to 
the following drawings, in conjunction with the accom- 
panying specification, in which 

FIG.1 shows a communication architecture in which is 
the present invention may be used 

FIG. 2 shows the secure pervasive access architec- 
ture as used by the present invention 

20 

FIG. 3 shows authentication and access via secure 
pervasive access as used by the present inven- 
tion 

FIG.4 shows the basic method steps of the present 25 
invention 

FIG. 5 shows the method of the delivery module as 
preferably used by the present invention 

30 

FIG. 6 shows the method of the PVC-Proxy as prefer- 
ably used by the present invention 

Detailed description of the preferred embodiment 

35 

[0016] Before going into details of specific embodi- 
ments, it will be helpful to understand from a more gen- 
eral perspective the various elements and methods 
which may be related to the present invention. 
[0017] An important feature of the present invention *o 
is the Secure Pervasive Access Framework (SPAF). 
SPAF builds the interface to various components of the 
invention. It receives the requests from the different 
PVC-devices, checks the security state of the respective 
PVC-device and gives access to the requested func- *s 
tions/application if the access conditions defined by the 
security policy are fulfilled. The security state of the re- 
spective PVC-device may be checked by own pro- 
grams, e.g. plug-ins, using authentication mechanism 
like password/userlD, challenge response, digital signa- so 
ture and so on. These plug-ins are totally independent 
from any application/function to be accessed. Access to 
an application/function will be exclusively controlled by 
the SPAF via the security policy. Security level of a cer- 
tain application/function may be changed without ss 
changing application function to be accessed. The ap- 
plication logic itself remains unchanged. This is an im- 
portant advantage of the present invention. 



[0018] Another feature of the present invention - 
which may be used optionally - is the Device Adaptation 
Layer (DAL). 

[001 9] It receives device specific requests and gener- 
ates a canonical form which is able to specify informa- 
tion about the device type and the desired reply content. 
The information contained in the canonical request is 
used for executing the respective authentication mech- 
anism by using the appropriate plug-in. The DAL is able 
to support any protocol, e.g. HTTPS and WAP. 
[0020] FIG.1 provides a view of a communication ar- 
chitecture in which the present invention may be used 
preferably. 

Currently many PVC-devices (6) are available on the 
market. The famous PVC-devices are personal digital 
assistants, mobile phones or WAP phones and chip- 
cards. 

[0021] One Server (2) hosts application functions (1 ) 
which may be accessed from different PVC-devices (6) 
with different levels of authentication and different levels 
of confidentiality od exchanged data. The other server 
hosts a PVC-Proxy (3), the Voice Gateway (4) and the 
WAP Gateway (5). 

[0022] The PVC-Proxy (3) allows to establish connec- 
tions to different kinds of PVC-devices (6) and maintains 
session information (cookies) and device type informa- 
tion for these connections. Connections to clients can 
be established directly or via the Voice Gateway (4) or 
WAP Gateway (5). Each incoming request is augment- 
ed by the session and devices type information before 
forwarding it to its destination. 

[0023] The Voice Gateway (4) includes speech rec- 
ognition and speech synthesis. It converts voice input 
from a telephone to HTTP requests and responses con- 
taining VXML-like content back to voice. 
[0024] The WAP Gateway (5) forwards WAP requests 
as HTTP requests to a server and returns the HTTP re- 
sponses to devices as WAP responses. 
[0025] Which content representation has to be used 
for a particular request is determined by the device info 
that comes with each request. Which session info has 
to be used is determined by the cookie information that 
is contained in each request. Setting the cookie infor- 
mation and the device info to appropriate values is the 
responsibility of the PVC-Proxy. 

[0026] FIG. 2 provides drawing of a preferred imple- 
mentation of a secure pervasive access architecture. 
[0027] The secure pervasive access architecture 
preferably comprises following components: 

a Device Adaptation Layer (DAL; 26) as gateway 
for the different PVC-devices (20) 

authentication component (27) comprising one or 
more security plug-ins (SP;28) for executing au- 
thentication mechanism 

a Secure Pervasive Access Framework (SPAF; 29) 
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a security policy (30) which is preferably laid down 
in a data base (31 ) accessible by the server 

several access protected application functions (32) 
located on the server or on a data base (33) acces- 
sible by the server 

[0028] The communication structure between these 
components is as follows: The single PVC-device (20) 
generates a device specific request and sends it to the 
DAL (26). Requests are routed through the DAL. Pref- 
erably DAL includes different kind of gateways that con- 
vert device specific requests into a canonical form, e.g. 
HTTP requests that includes information about device 
type and desired reply content type, e.g. HTML, WML 
or VXML. 

The appropriate security plug-ins (28) is selected based 
on the information contained in the request and an au- 
thentication mechanism as laid down in the selected se- 
curity plug-in (28) will be executed. The result of the au- 
thentication for the PVC-device called security state is 
stored in a non-volatile memory of the server. Then, the 
SPAF (29) compares the security state of a PVC-device 
with the associated security policy (30) for that applica- 
tion function (32) and invokes application function (32) 
according to the security policy. The security policy (30) 
comprises correlation of security levels concerning de- 
fined user-actions for accessing application functions. 
For example, the security policy may be implemented in 
a table in which each application function could have 
one or more correlation of security level concerning de- 
fined user-actions of that application function. The se- 
curity policy may be different depending from the type 
of information to be accessed or type of PVC-device. 
For example one non-sensitive application function may 
only have function accessible to everybody, while an- 
other application function may have functions that may 
only be performed by PVC-devices that have been au- 
thenticated by the security plug-ins or security modules 
using cryptographic protocol. The security policy may 
be stored in a special data base. 

[0029] SPAF compares security state delivered by the 
security plug-in with security policy associated with the 
respective application function. If the security state of 
the PVC-device satisfies the access conditions defined 
by the security policy the SPAF invokes the requested 
application function. 

[0030] FIG. 3 provides a drawing showing authentica- 
tion and access via secure pervasive access. 
[0031] PVC-devices (34) like mobile, personal digital 
assistants, chipcards generates a device specific re- 
quest and sends that request to the DAF (39). If a con- 
version is required DAF converts the device specific re- 
quest into a canonical request including a cookie. A 
cookie contains a packet of information which the server 
sends to DAF or the PVC-device to be sent back by the 
DAF or PVC device every time it reconnects with the 
that server. Cookies are mainly used to authenticate the 
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PVC-device against the server. Some PVC-devices do 
not support handling of cookies, e.g. WAP phone or per- 
sonal digital assistant. For these devices DAF (39) of- 
fers the functionality to support cookies. 

5 [0032] Cookies will be generated as follows: PVC -de- 
vice initiates by means of requests a communication via 
DAF (if necessary) with the SPAF (40) offering access 
to applications. The request contains information for au- 
thentication of the PVC-device, e.g. user ID and/or pass- 

10 word. 

[0033] Security plug-in or authentication servlets (35) 
using a specific authentication mechanism and if the au- 
thentication succeeds then the SPAF (40) creates a new 
session object with an associated session ID (43). Then 
15 the SPAF (40) uses the security state for the already 
authenticated PVC-device comprising result of the au- 
thentication and authentication information or parts of it 
contained in the request of the PVC-device and puts the 
security state (42) into the session object. SPAF (40) 
assigns a sessionID to the PVC-device and returns a 
response with a cookie containing the sessionID. The 
PVC device or DAF receives the response and stores 
the cookie. Each subsequent request send back by the 
PVC device to the SPAF contains that cookie. 
[0034] PVC-device (34) sends new request to the 
SPAF to access an application function, e.g. query con- 
fidential information. SPAF gets the sessionID from the 
cookie contained in that request, looks for the session 
object associated with that sessionID from the cookie 
and gets the security state contained in that session ob- 
ject. Then, SPAF checks security state contained in that 
session object with the security policy (41 ). If the secu- 
rity state (42) satisfies the security policy (41 ) the SPAF 
invokes the requested application function and returns 
a response. The PVC-device displays the response. 
[0035] FIG.4 provides a diagram showing the basic 
method steps of the present invention. 
[0036] The basic method comprises the step of "get 
security state from the session (45)" , checking the re- 
ceived security state with the security policy (46) and 
calling the requested application function (47) if the se- 
curity policy allows access to that application function. 
The security state will be preferably handled by security 
plug-ins as already explained above. Each plug-in con- 
tains one authentication mechanism, e.g. authentication 
by userlD/password, Challenge/Response, digital sig- 
nature. The plug-ins are independent from the applica- 
tion function to be invoked. 

[0037] The method steps for checking the received 
security state and allowing access to the desired appli- 
cation function are laid down in the Secure Pervasive 
Access Framework (SPAF). SPAF has an common in- 
terface to the accessible application functions. 
[0038] FIG.5 provides the method steps of the Deliv- 
ery Module for each outgoing response. 
[0039] The Delivery Module renders the information 
into content that depends on the device type and desired 
reply content type. Which content of representation has 
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to be used for a particular request is determined by the 
device info contained in each request (51 , 52). For each 
content type, e.g. HTML, WML or VXML, there are dif- 
ferent kind of Java Server Pager (JSPs) for content ren- 
dering. JSP can be used to generate arbitrary content 5 
by using the appropriate JSP tag to define the desired 
content type (53, 54). 

FIG. 6 provides the basic functionality of the PVC proxy. 
As already explained above the PVC-proxy support 
those PVC-devices which do not support handling of 10 
cookies. Proxy receives the cookies sent by the server 
and includes the cookie in the request of the appropriate 
PVC-device. 

Furthermore, the PVC-proxy converts the PVC-device 
specific requests into canonical requests as far it is re- 1$ 
quired. 

Claims 

20 

1 . Security system for controlling access to application 
functions (32;44) located on a server or accessible 
via a server, wherein clients (20; 34) communicate 
with said server by means of requests for accessing 
one of said application functions (32; 44) using 25 
wired, wireless, partly wireless network, wherein 
access to said application functions is controlled by 
security requirements, comprising: 

an authentication component (27) functionally 30 
separated from said clients (20; 34) and said 
application functions (32; 44) for processing cli- 
ent's request independently of client's type, 
containing different authentication mechanism 
(28) and selecting and executing an authenti- 35 
cation mechanism (28) based on the informa- 
tion contained in the client's request resulting 
in a security state (42); 

a security component (29; 40) containing a se- *o 
curity policy (30; 41) describing security re- 
quirements (security level) for accessing appli- 
cation functions, comparing security state (42) 
associated to a client with the security level of 
the application function and allowing access to 4 $ 
the specified application function if the security 
state fulfills the requirements of the security lev- 
el. 

2. System according to claim 1, wherein said clients so 
(20; 34) are PVC-devices. 

3. System according to claim 1 , wherein said authen- 
tication component (27) and said security compo- 
nent (29; 40) are integrated in one component 55 
stored on a server. 

4. System according to claim 1 , whereby said authen- 



tication component (27) consists of security plug- 
ins (28) whereby each authentication mechanism is 
laid down in a separate security plug-in. 

5. System according to claim 4, whereby the authen- 
tication mechansim (28) may be UserlD/Password, 
Challenge/Response or digital signature. 

6. System according to 2 further comprises: 

a component (ADL; 26; 39) for converting PVC-de- 
vice specific requests into canonical requests be- 
fore said request is used by said authentication 
component (27). 

7. Method for controlling access to application func- 
tions stored on a server or accessible via server, 
wherein clients communicate with said server by 
means of requests for accessing one of said appli- 
cation functions using wired, wireless or partly wire- 
less network, whereby access to said application 
functions is controlled by a security requirements, 
comprising the steps of: 

routing all incoming requests created by said clients 
(26; 34) to an authentication component (27) which 
is functionally independent from said clients and 
said application functions (32; 44), said authentica- 
tion component (27) comprises the steps of: 

authentication of said client by determining an 
authentication mechanism provided by said au- 
thentication component by means of authenti- 
cation information contained in said request 
and applying said authentication mechanism 

storing result of said authentication and said 
authentication information or parts of it con- 
tained in said request (security state) 

using security requirements for application 
function to be accessed 

comparing stored security state (42) with said 
security requirements (41 ) for accessing the re- 
quested application function 

invoking requested application function if secu- 
rity state fulfills said security requirements. 

8. Method according to claim 7 wherein said incoming 
requests are canonical requests. 

9. Method according to claim 8 wherein said canonical 
requests are created by a Device Adaptation Layer 
(26; 39) which converts client specific requests into 
canonical requests. 

10. Method according to claim 7 comprises the further 
steps of: 
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creating a session identifier (43) when establishing 
a communication between a client and a server and 
using said session identifier in all requests and re- 
sponses between said client and said server. 

5 

11. M ethod according to claim 1 0 whereby said session 
identifier (43) and said security state (42) are laid 
down in a cookie, whereby said cookie is inserted 
into each request and response between client and 
server. 10 



12. Method according to claim 7 wherein said clients 
are PVC-devices. 



1 3. A computer program comprising computer program 15 
code portions for performing respective steps of the 
method according to claim 7 to 12 when the pro- 
gram is executed in a computer. 

14. Computer program product stored on a computer- 20 
readable media containing software code for per- 
forming of the method according to one of the claim 

7 to 12 if the program product is executed on the 
computer. 

25 

15. Client-Server system, wherein clients (20;34) com- 
municate with said server by means of requests for 
accessing application functions (32;34) located on 
or accessible via said server, wherein access to 
said application functions is controlled by a security 30 
system located on said server, wherein said secu- 
rity system comprising: 



an authentication component (27) functionally 
separated from said clients and said application 35 
functions for processing client's request inde- 
pendently of client's type, containing different 
authentication mechanism (28) and selecting 
and executing an authentication mechanism 
based on the information contained in the cli- 40 
ent's request resulting in a security state (42); 



a security component (29;40) containing a se- 
curity policy (30;41) describing security re- 
quirements (security level) for accessing appli- 4 $ 
cation functions, comparing security state (42) 
associated to a client with the security level of 
the application function and allowing access to 
the specified application function if the security 
state fulfills the requirements of the security lev- 50 
el. 
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